home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Mar 90 / MacApp.Tech$ 3⁄2⁄90 / 0770-ClickCount Bug-Feb90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  2.3 KB  |  55 lines  |  [TEXT/GEOL]
  1. Item    8671166                         26-Feb-90        18:36PST
  2.  
  3. From:   MADA2                           MacApp Dev Assoc, Curtis Faith,IVC
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.         MACAPP.TEST                     MacApp SQA Team
  7.         MACDTS                          Macintosh Developer Tech. Supt.
  8.  
  9. Sub:    ClickCount Bug
  10.  
  11. I believe that there is a bug in the current implementation of click counting.
  12.  
  13. I was running into a problem with my TreeSaver application in a TTextListView
  14. when the user double-clicked, did not release after the second click, moved the
  15. mouse considerably thereby highliting another cell and then released it.  The
  16. effect of this was that gClickCount was 2, but the mouse was released in an
  17. entirely different section of the list.
  18.  
  19. Now for clickcounts of 2 or more my code would normally assume that the cell in
  20. question is already selected.  Thus it does not bother reinstalling the
  21. associated data.
  22.  
  23. This is not enough.  It is in fact possible for gClickCount to be greater than
  24. 1 when the mouse is actually many cells away.
  25.  
  26. 2 changes should be made to MacApp:
  27.  
  28. 1) ClickCounts should be dependent on the mouse-up coordinates.  It is not
  29. sufficient to rely on moused-down coordinates, since one can move the mouse
  30. considerably.
  31.  
  32. 2) ClickCount time should also be dependant on the time of the 2nd (or 3rd)
  33. mouse release.  It should not be considered a double click if the mouse remains
  34. down for an extended period of time after the mouse down.
  35.  
  36. This is not as trivial a change as it might seem.  The current implementation
  37. checks the clickCount in TApplication.HandleMouseDown.  This is before the
  38. mouse has been released.  The mouse won't actually have been released until
  39. after the StillDown loop at the end of TApplication.TrackMouse.
  40.  
  41. Thus it is not until TrackRelease that a Command would have a chance to know
  42. for certain that it was dealing with a legitimate multiple-click.
  43.  
  44. I propose that a test be placed inside TrackMouse to double check the
  45. clickCount after TrackRelease and decrement it if CountClicks thought it was a
  46. multiple-click and the conditions are no longer met on mouse release.
  47.  
  48. It would be up to each mouse command that depended on a click-Count to wait
  49. until track-release to do any multi-click specialized actions.
  50.  
  51. Regards,
  52.  
  53. Curtis
  54.  
  55.